I'm writing to express my frustration and disbelief that this critical bug is still present in production as of 2026.
We just completed a major refactoring effort, migrating our application from iCloud-based static file storage to SwiftData with CloudKit sync. During this migration, we encountered this exact issue and was stunned to discover it was already documented in 2024.
Here one of several specific scenarios:
Logbook view structure: @Bindable var logbook: Logbook (where Logbook is a @Model class)
The logbook.flights relationship array is not observed - changes to the array don't trigger view updates
Attempted workaround using @Query var flights: [Flight] - still not observed
This affects one of our primary user-facing views (flight logbook table)
Why the suggested workaround doesn't work:
The proposed solution of triggering refreshes on modelContext.didSave notifications is impractical for real-world applications:
• Context saves can occur multiple times throughout the app's lifecycle
• Frequent UI refreshes cause jarring user experience
• Table selections are lost on every refresh
• State management becomes a nightmare when you can't trust the observation system
This is unacceptable:
• It's been two years since this was first reported
• SwiftData was marketed as a production-ready replacement for Core Data
• Basic observation of to-many relationships should be fundamental functionality
• The workarounds compromise UX and require architectural gymnastics
We need either:
A proper fix for relationship observation
Official guidance on the correct architectural pattern
Acknowledgment that either SwiftData or @Query aren't ready for production use with CloudKit sync
This bug is blocking legitimate use cases and forcing developers to choose between broken observation or constant, disruptive UI refreshes.
When can we expect a real solution?
Topic:
App & System Services
SubTopic:
iCloud & Data
Tags: